Petter Reinholdtsen

Nikita-prosjektet, der jeg er involvert, inviterer i samarbeid med Oslo Byarkiv, forskningsgruppen METAINFO og foreningen NUUG, til et frokostseminar om Noark 5 og Noark 5 Tjenestegrensesnitt tirsdag 2024-03-12. Seminaret finner sted ved Oslo byarkiv. Vi håper å få til videostrømming via Internett av presentasjoner og paneldiskusjon. Oppdatert program og lenker til påmeldingsskjema er tilgjengelig fra Nikita-prosjektet. Arrangementet er gratis.

Som vanlig, hvis du bruker Bitcoin og ønsker å vise din støtte til det jeg driver med, setter jeg pris på om du sender Bitcoin-donasjoner til min adresse 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b. Merk, betaling med bitcoin er ikke anonymt. :)

I følge Ivar Johansen er det ca ti år siden Finanskomiteen i Oslo kommune vedtok "Byrådet bes legge til rette for at en elektronisk oversikt over alle kommunale eiendommer er tilgjengelig for oppslag på kommunens nettsider." Har ikke klart å finne vedtaket i offisielle nettsider fra kommunen, men i og med at kommunen har publisert oversikt over eiendommer de eier selv, desverre sist oppdatert for fire år siden (juni 2017), så kan det virke som vedtaket i hvert fall for en periode tok effekt.

Oversikten fra kommunen er et regneark med tomter og bygg, med tilhørende metainformasjon om adresse, areal etc. Det er jo et greit datagrunnlag, men ikke spesielt egnet for å få oversikt. Det inspirerte meg til å lage en KML-fil der informasjon fra kommunens liste kombineres med geografisk posisjon og utstrekning fra Matrikkelen slik den vises frem på Kartverkets tjeneste Se Eiendom, og slik få et interaktivt kart som viser komunens eiendommer. I første omgang viser den de 6824 tomtene i listen over eiendommer i Oslo kommune (og ikke utenbys tomter), unntatt de 268 gårds- og bruksnummerene uten informasjon om geografisk posisjon i Matrikkelen og de 346 gårds- og bruksnummerene som mangler helt i Matrikkelen. Det er vanskelig å vite hvilke av de sistenevnte som er feil i datagrunnlaget fra kommunen og hvilke som er et resultat av utdatert informasjon i et fire år gammelt datasett. Mer om det senere.

Hvis du vil se på KML-datasettet, så kan du enten gjøre som meg, bruke Marble på Linux, eller du kan laste ned et av de mange andre verktøyene som leser KML-filer, som Google Earth, JOSM og QGis. Har desverre ikke funnet en nettjeneste som kan vise frem filen i en nettleser, på grunn av filstørrelsen. Fant en OpenstreetMap-basert nettside som håndterte mindre filer, men den ga opp da hele kommunens areal var inkludert i filen.

KML-datasettet kan lastes ned her fra min blogg. Tomter med bygninger i følge matrikkelen er markert i rødt, mens tomter uten bygninger er markert i blått. De få tomtene med posisjon men uten utstrekning (tror alle er under bakken) har kun fått posisjonsmarkører. Jeg har i denne omgang begrenset meg til tomter og ikke tegnet inn hus, da jeg ikke fant noen enkel måte å hente ut geografisk utstrekning for husene basert på informasjonen i kommunens datasett. Konkret mangler jeg sikker måte å identifisere enkeltbygninger basert på kommunens oversikt. Vedlagt er et skjermbilde fra Marble som viser hvordan det kan se ut.

På grunn av oppløsningen viser ikke bildet alle gatene og mindre eiendommer i sentrum som er eid av kommunen. Dette vises når en dykker ned i materialet med en KML-fremviser. Jeg har ikke regnet på det, men visuelt ser det ut som om kommunen eier 25-30% av alt arealet i kommunen, hvilket jeg fant overraskende. Lurer på hvor stor del av arealet i Oslo totalt som er eid av ulike offentlige aktører. Vet jo at ulike departementer, direktorater, fylkeskommuner, kommunale pensjonskasser, og offentlig majoritetseide selskaper også eier en god del av eiendommene i Oslo. Det hadde vært interessant å vise frem, men mistenker innsynsforespørslene for å få tak i det datasettet kommer til å være en kamp i motbakke, både hvis en forsøker hver enkelt offentlig instans eller Matrikkelen.

Fra kartet kan en se at endel tomtearealer er markert flere ganger. Det skjer hvis kommunens oversikt henviser til matrikkel-tomter med overlappende areal. Hvis det finnes to ulike arealer med og uten bygninger så blir fargen lilla, ellers blir fargen sterkere enn hvis det bare et gårds- og bruksnummer for et gitt areal. Jeg antar dette kommer av utdatert informasjon i oversikten fra kommunen kombinert med tilgang på geografisk informasjon om ikke lenger gjeldende tomter i Matrikkelen, for eksempel ved at en eiendom er delt i flere biter, og kommunens oversikt inneholder oppføring av gårds- og bruksnummer før og etter oppdeling. Hver av disse bør undersøkes og korrigeres individuelt, men i og med at jeg ikke har mulighet til å fikse feil hos hverken kommunen eller kartverket har jeg ikke brukt tid på dette.

Det norske eiendomsregisteret, Matrikkelen, endres hele tiden. Det skjer blant annet ved ved fradeling og sammenslåing. Fire år er lang tid i så måte. Jeg antar det kan forklare noen av eiendommene kommunen hevder å eie som mangler informasjon i Matrikkelen, men neppe alle. Noen av dem er nok også feil i kommunens datasett. Utfordringen er å finne hvilke det gjelder. Hvis du har lyst til å se på detaljene, så er lenker til aktuelle gårds- og bruksnummer for de to problematiske kategoriene samlet under.

Et eksempel i så måte er 0301-999/11, som kommunens oversikt forteller er "GULLKROKEN 4M IKKE TINGLYST VEI" med Bymiljøetaten som ansvarlig etat, og kartverket sier er 0 kvadratmeter og uten registrerte teiger. Mitt gjett her er at kommunen ikke har registrert det jeg mistenker kan være veien til husene i lokalområdet i Matrikkelen, det vil si veien er fradelt fra 0301-31/244, og at kommunen så langt ikke har registrert teigen i Matrikkelen, men kan ikke vite sikkert. Det virker litt rart at det ikke er gjort på de fire årene som har gått siden oversikten fra kommunen ble publisert.

Dette er de 268 gårds- og bruksnummerene uten informasjon om geografisk posisjon i Matrikkelen: 2/173, 2/174, 2/384, 2/58, 3/133, 3/164, 3/346, 3/347, 3/348, 3/349, 3/368, 3/635, 5/14, 5/64, 5/78, 6/187, 6/219, 6/25, 6/56, 6/59, 9/147, 9/149, 9/155, 9/156, 9/158, 9/159, 10/385, 10/445, 27/2382, 27/677, 27/716, 27/75, 28/430, 30/47, 31/194, 31/195, 33/1083, 33/11, 33/1194, 33/1195, 33/1196, 33/1197, 33/1198, 33/1199, 33/1239, 33/330, 33/345, 33/346, 33/347, 33/348, 33/458, 33/512, 34/3, 35/435, 35/675, 36/185, 36/38, 37/101, 37/25, 38/203, 38/234, 38/235, 41/193, 41/381, 41/406, 47/19, 47/2, 47/75, 47/76, 49/3, 50/10, 50/11, 50/12, 50/13, 50/233, 50/9, 52/1143, 53/253, 53/35, 54/264, 54/265, 57/279, 57/297, 58/173, 58/196, 58/197, 59/239, 59/66, 64/9, 65/20, 66/15, 66/22, 69/15, 69/20, 69/38, 69/39, 69/40, 69/41, 69/42, 69/43, 70/3, 70/4, 70/6, 72/182, 72/25, 72/26, 72/27, 73/313, 73/638, 73/673, 73/719, 74/8, 77/153, 77/154, 77/155, 77/156, 77/157, 77/22, 79/25, 79/74, 86/50, 86/513, 86/515, 88/209, 88/210, 88/211, 90/536, 93/158, 93/200, 93/204, 93/205, 93/207, 93/208, 93/217, 93/218, 93/351, 93/5, 93/603, 94/531, 94/81, 95/16, 96/180, 97/44, 98/12, 98/13, 98/14, 98/19, 102/424, 102/447, 104/6, 105/188, 105/189, 107/167, 109/3, 112/24, 112/27, 114/23, 120/13, 122/19, 122/25, 122/369, 126/95, 126/96, 126/97, 127/11, 127/67, 131/31, 137/121, 138/16, 140/120, 141/26, 144/692, 146/200, 146/201, 146/202, 146/203, 146/204, 146/205, 146/206, 146/207, 146/208, 146/209, 146/210, 146/211, 146/557, 147/54, 148/503, 149/429, 149/958, 150/107, 151/281, 151/6, 152/162, 152/20, 154/24, 157/214, 162/286, 166/3, 168/31, 168/5, 171/31, 171/6, 174/4, 177/5, 182/109, 182/114, 182/147, 182/344, 182/652, 182/725, 182/727, 182/728, 182/729, 182/744, 182/936, 191/171, 194/49, 196/66, 197/216, 197/218, 197/305, 197/358, 198/16, 208/439, 209/321, 209/322, 209/377, 212/21, 213/33, 213/74, 214/468, 215/248, 215/44, 216/166, 216/82, 219/200, 219/300, 221/276, 221/58, 222/124, 222/6, 224/185, 224/346, 224/93, 225/231, 225/306, 225/32, 225/400, 225/414, 228/22, 228/47, 230/310, 231/142, 231/144, 231/23, 231/521, 233/169, 233/176, 233/178, 233/301, 234/52, 234/53, 236/76, 236/9, 441/1, 480/1, 999/11 og 999/134

Dette er de 346 gårds- og bruksnummerene som mangler i Matrikkelen (Matrikkelen sier "eiendommen er utgått"): 2/559, 2/563, 2/641, 2/642, 3/555, 5/111, 11/598, 11/608, 27/2113, 27/2261, 27/326, 27/405, 27/644, 28/363, 28/446, 28/447, 28/491, 28/492, 28/493, 28/494, 28/495, 28/496, 28/497, 31/218, 31/352, 31/353, 31/356, 31/359, 31/383, 31/384, 31/420, 31/425, 31/427, 31/434, 31/437, 32/433, 32/434, 32/435, 32/436, 32/815, 33/1088, 33/1224, 33/1237, 33/1238, 33/1258, 33/1339, 33/1340, 33/1341, 33/1342, 33/203, 33/302, 33/4, 33/7, 33/8, 33/809, 33/810, 33/813, 33/870, 34/7, 35/469, 35/470, 36/189, 36/191, 36/192, 36/193, 36/194, 44/0, 52/1109, 52/1197, 53/484, 54/181, 54/185, 54/200, 54/201, 54/202, 54/203, 73/135, 73/159, 73/466, 73/614, 73/615, 73/616, 73/617, 73/618, 73/619, 73/620, 73/621, 73/633, 73/672, 73/674, 73/675, 73/676, 73/678, 73/679, 73/687, 73/794, 75/598, 75/599, 75/600, 75/601, 75/602, 75/603, 75/604, 75/605, 75/607, 75/608, 75/610, 75/611, 75/613, 75/616, 75/617, 75/618, 75/619, 75/620, 75/622, 75/734, 75/763, 75/764, 75/765, 75/766, 75/767, 75/768, 75/769, 75/770, 75/771, 75/772, 75/773, 75/774, 75/775, 75/776, 75/777, 75/778, 75/779, 75/780, 75/781, 75/782, 75/783, 76/145, 76/146, 76/147, 76/148, 76/149, 76/150, 76/151, 76/152, 76/153, 76/154, 76/155, 76/156, 76/157, 76/158, 85/23, 86/541, 86/922, 88/222, 91/143, 92/121, 92/171, 92/90, 93/283, 93/284, 93/285, 94/11, 94/436, 94/503, 94/504, 94/6, 95/307, 95/50, 105/380, 105/476, 106/263, 122/103, 122/110, 122/111, 122/309, 122/337, 123/778, 128/116, 129/87, 130/172, 130/192, 132/59, 132/60, 132/61, 132/62, 132/63, 132/64, 132/65, 132/66, 132/67, 133/11, 138/97, 140/154, 141/47, 143/604, 144/1064, 144/1357, 144/150, 144/1895, 144/314, 144/814, 144/870, 144/871, 144/872, 144/873, 144/874, 144/875, 144/876, 144/877, 144/878, 144/969, 146/349, 148/179, 148/180, 148/181, 148/528, 149/986, 150/103, 151/237, 151/240, 151/255, 151/256, 151/268, 151/269, 151/270, 151/273, 151/274, 151/275, 151/277, 151/280, 151/291, 151/293, 151/299, 151/304, 151/338, 157/35, 159/245, 159/323, 159/338, 160/163, 164/247, 164/249, 167/313, 175/6, 176/25, 176/31, 177/7, 180/7, 190/222, 190/223, 190/225, 190/226, 190/227, 190/228, 190/229, 190/230, 190/231, 190/232, 191/69, 197/101, 197/117, 197/138, 197/145, 197/158, 197/159, 197/160, 197/167, 197/183, 197/22, 197/318, 197/68, 207/462, 207/75, 212/0, 223/38, 224/376, 225/178, 225/424, 225/425, 225/47, 229/152, 230/280, 230/282, 230/475, 230/476, 230/477, 230/478, 230/479, 230/94, 230/95, 230/96, 230/98, 232/62, 233/272, 233/273, 233/274, 233/502, 234/48, 235/53, 236/195, 250/41, 385/0, 485/0, 507/0, 509/0, 516/0, 517/0, 518/0, 999/109, 999/170, 999/221, 999/245, 999/25, 999/273, 999/283, 999/317, 999/338, 999/339, 999/349, 999/38, 999/394, 999/417, 999/471, 999/492, 999/58, 999/581, 999/601, 999/612, 999/636, 999/643, 999/646, 999/654, 999/655, 999/676, 999/76, 999/786, 999/788, 999/819, 999/822, 999/825, 999/849, 999/857, 999/862, 999/866 og 999/884

Som vanlig, hvis du bruker Bitcoin og ønsker å vise din støtte til det jeg driver med, setter jeg pris på om du sender Bitcoin-donasjoner til min adresse 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b. Merk, betaling med bitcoin er ikke anonymt. :)

Oppdatering 2020-07-05: Ble tipset om offisielle kilder fra kommunens behandling. Vedtaket var del av sak 133 i protokoll fra finanskomiteens møte onsdag 19. oktober 2011 kl. 16:30, og kom som resultat av følgende utveksling med spørsmål og svar.

I am very pleased to be able to share with you the announcement of a new version of the archiving system Nikita published by its lead developer Thomas Sødring:

It is with great pleasure that we can announce a new release of nikita. Version 0.6 (https://gitlab.com/OsloMet-ABI/nikita-noark5-core). This release makes new record keeping functionality available. This really is a maturity release. Both in terms of functionality but also code. Considerable effort has gone into refactoring the codebase and simplifying the code. Notable changes for this release include:

• Significantly improved OData parsing
• Support for business specific metadata and national identifiers
• Continued implementation of domain model and endpoints
• Improved testing
• Ability to export and import from arkivstruktur.xml

We are currently in the process of reaching an agreement with an archive institution to publish their picture archive using nikita with business specific metadata and we hope that we can share this with you soon. This is an interesting project as it allows the organisation to bring an older picture archive back to life while using the original metadata values stored as business specific metadata. Combined with OData means the scope and use of the archive is significantly increased and will showcase both the flexibility and power of Noark.

I really think we are approaching a version 1.0 of nikita, even though there is still a lot of work to be done. The notable work at the moment is to implement access-control and full text indexing of documents.

My sincere thanks to everyone who has contributed to this release!

- Thomas

Release 0.6 2021-06-10 (d1ba5fc7e8bad0cfdce45ac20354b19d10ebbc7b)

• Refactor metadata entity search
• Remove redundant security configuration
• Make OpenAPI documentation work
• Change database structure / inheritance model to a more sensible approach
• Make it possible to move entities around the fonds structure
• Implemented a number of missing endpoints
• Make sure yml files are in sync
• Implemented/finalised storing and use of
     
  • Business Specific Metadata
     
  • Norwegian National Identifiers
     
  • Cross Reference
     
  • Keyword
     
  • StorageLocation
     
  • Author
     
  • Screening for relevant objects
     
  • ChangeLog
     
  • EventLog
• Make generation of updated docker image part of successful CI pipeline
• Implement pagination for all list requests
     
  • Refactor code to support lists
     
  • Refactor code for readability
     
  • Standardise the controller/service code
• Finalise File->CaseFile expansion and Record->registryEntry/recordNote expansion
• Improved Continuous Integration (CI) approach via gitlab
• Changed conversion approach to generate tagged PDF documents
• Updated dependencies
     
  • For security reasons
     
  • Brought codebase to spring-boot version 2.5.0
     
  • Remove import of necessary dependencies
     
  • Remove non-used metrics classes
• Added new analysis to CI including
• Implemented storing of Keyword
• Implemented storing of Screening and ScreeningMetadata
• Improved OData support
     
  • Better support for inheritance in queries where applicable
     
  • Brought in more OData tests
     
  • Improved OData/hibernate understanding of queries
     
  • Implement $count, $orderby
     
  • Finalise $top and $skip
     
  • Make sure & is used between query parameters
• Improved Testing in codebase
     
  • A new approach for integration tests to make test more readable
     
  • Introduce tests in parallel with code development for TDD approach
     
  • Remove test that required particular access to storage
• Implement case-handling process from received email to case-handler
     
  • Develop required GUI elements (digital postroom from email)
     
  • Introduced leader, quality control and postroom roles
• Make PUT requests return 200 OK not 201 CREATED
• Make DELETE requests return 204 NO CONTENT not 200 OK
• Replaced 'oppdatert*' with 'endret*' everywhere to match latest spec
• Upgrade Gitlab CI to use python > 3 for CI scripts
• Bug fixes
     
  • Fix missing ALLOW
     
  • Fix reading of objects from jar file during start-up
     
  • Reduce the number of warnings in the codebase
     
  • Fix delete problems
     
  • Make better use of cascade for "leaf" objects
     
  • Add missing annotations where relevant
     
  • Remove the use of ETAG for delete
     
  • Fix missing/wrong/broken rels discovered by runtest
     
  • Drop unofficial convertFil (konverterFil) end point
     
  • Fix regex problem for dateTime
     
  • Fix multiple static analysis issues discovered by coverity
     
  • Fix proxy problem when looking for object class names
     
  • Add many missing translated Norwegian to English (internal) attribute/entity names
     
  • Change UUID generation approach to allow code also set a value
     
  • Fix problem with Part/PartParson
     
  • Fix problem with empty OData search results
     
  • Fix metadata entity domain problem
• General Improvements
     
  • Makes future refactoring easier as coupling is reduced
     
  • Allow some constant variables to be set from property file
     
  • Refactor code to make reflection work better across codebase
     
  • Reduce the number of @Service layer classes used in @Controller classes
     
  • Be more consistent on naming of similar variable types
     
  • Start printing rels/href if they are applicable
     
  • Cleaner / standardised approach to deleting objects
     
  • Avoid concatenation when using StringBuilder
     
  • Consolidate code to avoid duplication
     
  • Tidy formatting for a more consistent reading style across similar class files
     
  • Make throw a log.error message not an log.info message
     
  • Make throw print the log value rather than printing in multiple places
     
  • Add some missing pronom codes
     
  • Fix time formatting issue in Gitlab CI
     
  • Remove stale / unused code
     
  • Use only UUID datatype rather than combination String/UUID for systemID
     
  • Mark variables final and @NotNull where relevant to indicate intention
• Change Date values to DateTime to maintain compliance with Noark 5 standard
• Domain model improvements using Hypersistence Optimizer
     
  • Move @Transactional from class to methods to avoid borrowing the JDBC Connection unnecessarily
     
  • Fix OneToOne performance issues
     
  • Fix ManyToMany performance issues
     
  • Add missing bidirectional synchronization support
     
  • Fix ManyToMany performance issue
• Make List<> and Set<> use final-keyword to avoid potential problems during update operations
• Changed internal URLs, replaced "hateoas-api" with "api".
• Implemented storing of Precedence.
• Corrected handling of screening.
• Corrected _links collection returned for list of mixed entity types to match the specific entity.
• Improved several internal structures.

If free and open standardized archiving API sound interesting to you, please contact us on IRC (#nikita on irc.oftc.net) or email (nikita-noark mailing list).

As usual, if you use Bitcoin and want to show your support of my activities, please send Bitcoin donations to my address 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

Today, after many months of development, a new release of Nikita Noark 5 core project was finally announced on the project mailing list. The Nikita free software solution is an implementation of the Norwegian archive standard Noark 5 used by government offices in Norway. These were the changes in version 0.5 since version 0.4, see the email link above for links to a demo site:

• Updated to Noark 5 versjon 5.0 API specification.
  • Changed formatting of _links from [] to {} to match IETF draft on JSON HAL.
  • Merged Registrering og Basisregistrering in version 4 to combined Registrering.
  • DokumentObjekt is now subtype of ArkivEnhet.
  • Introducing new entity Arkivnotat.
  • Changed all relation keys to use /v5/ instead of /v4/.
  • Corrected to use new official relation keys when possible.
  • Renamed Sakspart to Part and connect it to Mappe, Registrering and Dokumentbeskrivelse instead of only Saksmappe.
  • Moved Korrespondansepart connection from Journalpost to Registrering.
  • Moved Part and Korrespondansepart from package sakarkiv to arkivstruktur.
  • Renamed presedensstatus to presedensStatus.
  • Use new JSON content-type "application/vnd.noark5+json".
  • Updated prepopulated format list to use PRONOM codes.
  • Implemented endpoint for system information.
  • Implemented national identifiers for both file and record.
  • Implemented comments.
  • implemented sign off.
  • implemented conversion.
• Improved/implemented OData search and paging support for more entities.
• No longer exposes attribute Dokumentobjekt.referanseDokumentfil, one should use the relation in _links instead.
• Corrected relation keys under https://rel.arkivverket.no/noark5/v5/api/administrasjon/, replacing 'administrasjon' with 'admin'.
• Fixed several security and stability issues discovered by Coverity.
• Corrected handling ETag errors, now return code 409.
• Improved handling of Kryssreferanse.
• Changed internal database model to use UUID/SystemID as primary keys in tables.
• Changed internal database table names to use package prefix.
• Changed time zone handling for date and datetime attributes, to be more according to the new definition in the API specification.
• Change revoke-token to only drop token on POST requests, not GET.
• Updated to newer Spring version.
• Changed primary key and URL component for metadata code lists to use the 'kode' value instead of a SystemID.
• Corrected implementation of Part and Sakspart.
• Changed instance lists with subtypes (like .../registrering/ and .../mappe/) to include the attributes and _links entries for the subtype in the supertype lists.
• Adjusted _links relations to make it possible to figure out the entity of an instance using the self->href->relation key lookup method.
• Fixed several end points to make sure GET, PUT, POST and DELETE match each other.
• Updated DELETE endpoints to work with UUID based entity identifiers.
• Restructured code to use more common URL related constants in entry point values and replace @RequestMapping with method specific annotations.
• Added first unit test code.
• Updated web GUI to work with the updated API.
• Changed integer fields, enforce them as numeric.
• Rewrote and simplify metadata handling to use common service and controller code instead of duplicating for each type.
• Implemented the remaining metadata types.
• Changed Country list source from Wikipedia to Debian iso-codes and updated the list of Countries.
• Many many corrections and improvements.

If free and open standardized archiving API sound interesting to you, please contact us on IRC (#nikita on irc.freenode.net) or email (nikita-noark mailing list).

As usual, if you use Bitcoin and want to show your support of my activities, please send Bitcoin donations to my address 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

This morning, a new release of Nikita Noark 5 core project was announced on the project mailing list. The Nikita free software solution is an implementation of the Norwegian archive standard Noark 5 used by government offices in Norway. These were the changes in version 0.4 since version 0.3, see the email link above for links to a demo site:

• Roll out OData handling to all endpoints where applicable
• Changed the relation key for "ny-journalpost" to the official one.
• Better link generation on outgoing links.
• Tidy up code and make code and approaches more consistent throughout the codebase
• Update rels to be in compliance with updated version in the interface standard
• Avoid printing links on empty objects as they can't have links
• Small bug fixes and improvements
• Start moving generation of outgoing links to @Service layer so access control can be used when generating links
• Log exception that was being swallowed so it's traceable
• Fix name mapping problem
• Update templated printing so templated should only be printed if it is set true. Requires more work to roll out across entire application.
• Remove Record->DocumentObject as per domain model of n5v4
• Add ability to delete lists filtered with OData
• Return NO_CONTENT (204) on delete as per interface standard
• Introduce support for ConstraintViolationException exception
• Make Service classes extend NoarkService
• Make code base respect X-Forwarded-Host, X-Forwarded-Proto and X-Forwarded-Port
• Update CorrespondencePart* code to be more in line with Single Responsibility Principle
• Make package name follow directory structure
• Make sure Document number starts at 1, not 0
• Fix isues discovered by FindBugs
• Update from Date to ZonedDateTime
• Fix wrong tablename
• Introduce Service layer tests
• Improvements to CorrespondencePart
• Continued work on Class / Classificationsystem
• Fix feature where authors were stored as storageLocations
• Update HQL builder for OData
• Update OData search capability from webpage

If free and open standardized archiving API sound interesting to you, please contact us on IRC (#nikita on irc.freenode.net) or email (nikita-noark mailing list).

As usual, if you use Bitcoin and want to show your support of my activities, please send Bitcoin donations to my address 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

Yesterday, a new release of Nikita Noark 5 core project was announced on the project mailing list. The free software solution is an implementation of the Norwegian archive standard Noark 5 used by government offices in Norway. These were the changes in version 0.3 since version 0.2.1 (from NEWS.md):

• Improved ClassificationSystem and Class behaviour.
• Tidied up known inconsistencies between domain model and hateaos links.
• Added experimental code for blockchain integration.
• Make token expiry time configurable at upstart from properties file.
• Continued work on OData search syntax.
• Started work on pagination for entities, partly implemented for Saksmappe.
• Finalise ClassifiedCode Metadata entity.
• Implement mechanism to check if authentication token is still valid. This allow the GUI to return a more sensible message to the user if the token is expired.
• Reintroduce browse.html page to allow user to browse JSON API using hateoas links.
• Fix bug in handling file/mappe sequence number. Year change was not properly handled.
• Update application yml files to be in sync with current development.
• Stop 'converting' everything to PDF using libreoffice. Only convert the file formats doc, ppt, xls, docx, pptx, xlsx, odt, odp and ods.
• Continued code style fixing, making code more readable.
• Minor bug fixes.

If free and open standardized archiving API sound interesting to you, please contact us on IRC (#nikita on irc.freenode.net) or email (nikita-noark mailing list).

As usual, if you use Bitcoin and want to show your support of my activities, please send Bitcoin donations to my address 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

Jeg registrerer med glede at Stortinget i dag har vedtatt at det skal vedlikeholdes et åpent og maskinlesbart register over reelle rettighetshavere i Norge. Her kan en kanskje få et register som kan brukes til å analysere eierskap og kontroll i Norge maskinelt og knytte det til internasjonale databaser som OpenCorporates. Det liker jeg.

Den vedtatte grense på 25 prosents eierandel fikk stor oppmerksomhet i debatten. Jeg ser fra enkel analyse av skatteetatens eierskapsregister at 80.4% av alle selskapseiere i registeret har mindre enn 25% eierandel, mot 73.8% som har mindre enn 5% eierandel. En grense på 25% vil altså utelukke 80.4% av selskapseierne fra det vedtatte registeret, og en grense på 5% vil skjule 73.8%. En må helt ned i registrering av eierandeler over circa 0.002% for å få mer enn halvparten av selskapseierne i Norge. Mon tro hvor langt ned en må i eierprosent for å få med alle eierskapene til politisk valgte representanter?

Jeg biter meg også merke i at Sivert Bjørnstad fra FrP tilsynelatende tror at aksjonærregisteret er et eksisterende åpent register, på tross av at det så vidt jeg vet kun deles ved personlig oppmøte hos skatteetaten og ikke er tilgjengelig i maskinlesbart format for enhver, og dermed så langt ikke er importert inn i OpenCorporates. Det anser jeg ikke for et spesielt åpent register. Debatten ga ellers lite håp om at situasjonen bedrer seg, da finansministeren bare henviste til en fraværende næringsministeren og ikke ville uttale seg om et skikkelig aksjonærregister snart dukker opp.

Som vanlig, hvis du bruker Bitcoin og ønsker å vise din støtte til det jeg driver med, setter jeg pris på om du sender Bitcoin-donasjoner til min adresse 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b. Merk, betaling med bitcoin er ikke anonymt. :)

This morning, the new release of the Nikita Noark 5 core project was announced on the project mailing list. The free software solution is an implementation of the Norwegian archive standard Noark 5 used by government offices in Norway. These were the changes in version 0.2 since version 0.1.1 (from NEWS.md):

• Fix typos in REL names
• Tidy up error message reporting
• Fix issue where we used Integer.valueOf(), not Integer.getInteger()
• Change some String handling to StringBuffer
• Fix error reporting
• Code tidy-up
• Fix issue using static non-synchronized SimpleDateFormat to avoid race conditions
• Fix problem where deserialisers were treating integers as strings
• Update methods to make them null-safe
• Fix many issues reported by coverity
• Improve equals(), compareTo() and hash() in domain model
• Improvements to the domain model for metadata classes
• Fix CORS issues when downloading document
• Implementation of case-handling with registryEntry and document upload
• Better support in Javascript for OPTIONS
• Adding concept description of mail integration
• Improve setting of default values for GET on ny-journalpost
• Better handling of required values during deserialisation
• Changed tilknyttetDato (M620) from date to dateTime
• Corrected some opprettetDato (M600) (de)serialisation errors.
• Improve parse error reporting.
• Started on OData search and filtering.
• Added Contributor Covenant Code of Conduct to project.
• Moved repository and project from Github to Gitlab.
• Restructured repository, moved code into src/ and web/.
• Updated code to use Spring Boot version 2.
• Added support for OAuth2 authentication.
• Fixed several bugs discovered by Coverity.
• Corrected handling of date/datetime fields.
• Improved error reporting when rejecting during deserializatoin.
• Adjusted default values provided for ny-arkivdel, ny-mappe, ny-saksmappe, ny-journalpost and ny-dokumentbeskrivelse.
• Several fixes for korrespondansepart*.
• Updated web GUI:
  • Now handle both file upload and download.
  • Uses new OAuth2 authentication for login.
  • Forms now fetches default values from API using GET.
  • Added RFC 822 (email), TIFF and JPEG to list of possible file formats.

The changes and improvements are extensive. Running diffstat on the changes between git tab 0.1.1 and 0.2 show 1098 files changed, 108666 insertions(+), 54066 deletions(-).

If free and open standardized archiving API sound interesting to you, please contact us on IRC (#nikita on irc.freenode.net) or email (nikita-noark mailing list).

As usual, if you use Bitcoin and want to show your support of my activities, please send Bitcoin donations to my address 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

I am very happy to report that the Nikita Noark 5 core project tagged its second release today. The free software solution is an implementation of the Norwegian archive standard Noark 5 used by government offices in Norway. These were the changes in version 0.1.1 since version 0.1.0 (from NEWS.md):

• Continued work on the angularjs GUI, including document upload.
• Implemented correspondencepartPerson, correspondencepartUnit and correspondencepartInternal
• Applied for coverity coverage and started submitting code on regualr basis.
• Started fixing bugs reported by coverity
• Corrected and completed HATEOAS links to make sure entire API is available via URLs in _links.
• Corrected all relation URLs to use trailing slash.
• Add initial support for storing data in ElasticSearch.
• Now able to receive and store uploaded files in the archive.
• Changed JSON output for object lists to have relations in _links.
• Improve JSON output for empty object lists.
• Now uses correct MIME type application/vnd.noark5-v4+json.
• Added support for docker container images.
• Added simple API browser implemented in JavaScript/Angular.
• Started on archive client implemented in JavaScript/Angular.
• Started on prototype to show the public mail journal.
• Improved performance by disabling Sprint FileWatcher.
• Added support for 'arkivskaper', 'saksmappe' and 'journalpost'.
• Added support for some metadata codelists.
• Added support for Cross-origin resource sharing (CORS).
• Changed login method from Basic Auth to JSON Web Token (RFC 7519) style.
• Added support for GET-ing ny-* URLs.
• Added support for modifying entities using PUT and eTag.
• Added support for returning XML output on request.
• Removed support for English field and class names, limiting ourself to the official names.
• ...

If this sound interesting to you, please contact us on IRC (#nikita on irc.freenode.net) or email (nikita-noark mailing list).

This is a copy of an email I posted to the nikita-noark mailing list. Please follow up there if you would like to discuss this topic. The background is that we are making a free software archive system based on the Norwegian Noark 5 standard for government archives.

I've been wondering a bit lately how trusted timestamps could be stored in Noark 5. Trusted timestamps can be used to verify that some information (document/file/checksum/metadata) have not been changed since a specific time in the past. This is useful to verify the integrity of the documents in the archive.

Then it occured to me, perhaps the trusted timestamps could be stored as dokument variants (ie dokumentobjekt referered to from dokumentbeskrivelse) with the filename set to the hash it is stamping?

Given a "dokumentbeskrivelse" with an associated "dokumentobjekt", a new dokumentobjekt is associated with "dokumentbeskrivelse" with the same attributes as the stamped dokumentobjekt except these attributes:

• format -> "RFC3161"
• mimeType -> "application/timestamp-reply"
• formatDetaljer -> "<source URL for timestamp service>"
• filenavn -> "<sjekksum>.tsr"

This assume a service following IETF RFC 3161 is used, which specifiy the given MIME type for replies and the .tsr file ending for the content of such trusted timestamp. As far as I can tell from the Noark 5 specifications, it is OK to have several variants/renderings of a dokument attached to a given dokumentbeskrivelse objekt. It might be stretching it a bit to make some of these variants represent crypto-signatures useful for verifying the document integrity instead of representing the dokument itself.

Using the source of the service in formatDetaljer allow several timestamping services to be used. This is useful to spread the risk of key compromise over several organisations. It would only be a problem to trust the timestamps if all of the organisations are compromised.

The following oneliner on Linux can be used to generate the tsr file. $input is the path to the file to checksum, and $sha256 is the SHA-256 checksum of the file (ie the ".tsr" value mentioned above).

openssl ts -query -data "$inputfile" -cert -sha256 -no_nonce \
  | curl -s -H "Content-Type: application/timestamp-query" \
      --data-binary "@-" http://zeitstempel.dfn.de > $sha256.tsr

To verify the timestamp, you first need to download the public key of the trusted timestamp service, for example using this command:

wget -O ca-cert.txt \
  https://pki.pca.dfn.de/global-services-ca/pub/cacert/chain.txt

Note, the public key should be stored alongside the timestamps in the archive to make sure it is also available 100 years from now. It is probably a good idea to standardise how and were to store such public keys, to make it easier to find for those trying to verify documents 100 or 1000 years from now. :)

The verification itself is a simple openssl command:

openssl ts -verify -data $inputfile -in $sha256.tsr \
  -CAfile ca-cert.txt -text

Is there any reason this approach would not work? Is it somehow against the Noark 5 specification?

I disse dager, med frist 1. mai, har Riksarkivaren ute en høring på sin forskrift. Som en kan se er det ikke mye tid igjen før fristen som går ut på søndag. Denne forskriften er det som lister opp hvilke formater det er greit å arkivere i Noark 5-løsninger i Norge.

Jeg fant høringsdokumentene hos Norsk Arkivråd etter å ha blitt tipset på epostlisten til fri programvareprosjektet Nikita Noark5-Core, som lager et Noark 5 Tjenestegresesnitt. Jeg er involvert i Nikita-prosjektet og takket være min interesse for tjenestegrensesnittsprosjektet har jeg lest en god del Noark 5-relaterte dokumenter, og til min overraskelse oppdaget at standard epost ikke er på listen over godkjente formater som kan arkiveres. Høringen med frist søndag er en glimrende mulighet til å forsøke å gjøre noe med det. Jeg holder på med egen høringsuttalelse, og lurer på om andre er interessert i å støtte forslaget om å tillate arkivering av epost som epost i arkivet.

Er du igang med å skrive egen høringsuttalelse allerede? I så fall kan du jo vurdere å ta med en formulering om epost-lagring. Jeg tror ikke det trengs så mye. Her et kort forslag til tekst:

Viser til høring sendt ut 2017-02-17 (Riksarkivarens referanse 2016/9840 HELHJO), og tillater oss å sende inn noen innspill om revisjon av Forskrift om utfyllende tekniske og arkivfaglige bestemmelser om behandling av offentlige arkiver (Riksarkivarens forskrift).

Svært mye av vår kommuikasjon foregår i dag på e-post.  Vi foreslår derfor at Internett-e-post, slik det er beskrevet i IETF RFC 5322, https://tools.ietf.org/html/rfc5322. bør inn som godkjent dokumentformat.  Vi foreslår at forskriftens oversikt over godkjente dokumentformater ved innlevering i § 5-16 endres til å ta med Internett-e-post.

Som del av arbeidet med tjenestegrensesnitt har vi testet hvordan epost kan lagres i en Noark 5-struktur, og holder på å skrive et forslag om hvordan dette kan gjøres som vil bli sendt over til arkivverket så snart det er ferdig. De som er interesserte kan følge fremdriften på web.

Oppdatering 2017-04-28: I dag ble høringuttalelsen jeg skrev sendt inn av foreningen NUUG.

Jeg oppdaget i dag at nettstedet som publiserer offentlige postjournaler fra statlige etater, OEP, har begynt å blokkerer enkelte typer webklienter fra å få tilgang. Vet ikke hvor mange det gjelder, men det gjelder i hvert fall libwww-perl og curl. For å teste selv, kjør følgende:

% curl -v -s https://www.oep.no/pub/report.xhtml?reportId=3 2>&1 |grep '< HTTP'
< HTTP/1.1 404 Not Found
% curl -v -s --header 'User-Agent:Opera/12.0' https://www.oep.no/pub/report.xhtml?reportId=3 2>&1 |grep '< HTTP'
< HTTP/1.1 200 OK
%

Her kan en se at tjenesten gir «404 Not Found» for curl i standardoppsettet, mens den gir «200 OK» hvis curl hevder å være Opera versjon 12.0. Offentlig elektronisk postjournal startet blokkeringen 2017-03-02.

Blokkeringen vil gjøre det litt vanskeligere å maskinelt hente informasjon fra oep.no. Kan blokkeringen være gjort for å hindre automatisert innsamling av informasjon fra OEP, slik Pressens Offentlighetsutvalg gjorde for å dokumentere hvordan departementene hindrer innsyn i rapporten «Slik hindrer departementer innsyn» som ble publiserte i januar 2017. Det virker usannsynlig, da det jo er trivielt å bytte User-Agent til noe nytt.

Finnes det juridisk grunnlag for det offentlige å diskriminere webklienter slik det gjøres her? Der tilgang gis eller ikke alt etter hva klienten sier at den heter? Da OEP eies av DIFI og driftes av Basefarm, finnes det kanskje noen dokumenter sendt mellom disse to aktørene man kan be om innsyn i for å forstå hva som har skjedd. Men postjournalen til DIFI viser kun to dokumenter det siste året mellom DIFI og Basefarm. Mimes brønn neste, tenker jeg.

The Nikita Noark 5 core project is implementing the Norwegian standard for keeping an electronic archive of government documents. The Noark 5 standard document the requirement for data systems used by the archives in the Norwegian government, and the Noark 5 web interface specification document a REST web service for storing, searching and retrieving documents and metadata in such archive. I've been involved in the project since a few weeks before Christmas, when the Norwegian Unix User Group announced it supported the project. I believe this is an important project, and hope it can make it possible for the government archives in the future to use free software to keep the archives we citizens depend on. But as I do not hold such archive myself, personally my first use case is to store and analyse public mail journal metadata published from the government. I find it useful to have a clear use case in mind when developing, to make sure the system scratches one of my itches.

If you would like to help make sure there is a free software alternatives for the archives, please join our IRC channel (#nikita on irc.freenode.net) and the project mailing list.

When I got involved, the web service could store metadata about documents. But a few weeks ago, a new milestone was reached when it became possible to store full text documents too. Yesterday, I completed an implementation of a command line tool archive-pdf to upload a PDF file to the archive using this API. The tool is very simple at the moment, and find existing fonds, series and files while asking the user to select which one to use if more than one exist. Once a file is identified, the PDF is associated with the file and uploaded, using the title extracted from the PDF itself. The process is fairly similar to visiting the archive, opening a cabinet, locating a file and storing a piece of paper in the archive. Here is a test run directly after populating the database with test data using our API tester:

~/src//noark5-tester$ ./archive-pdf mangelmelding/mangler.pdf
using arkiv: Title of the test fonds created 2017-03-18T23:49:32.103446
using arkivdel: Title of the test series created 2017-03-18T23:49:32.103446

 0 - Title of the test case file created 2017-03-18T23:49:32.103446
 1 - Title of the test file created 2017-03-18T23:49:32.103446
Select which mappe you want (or search term): 0
Uploading mangelmelding/mangler.pdf
  PDF title: Mangler i spesifikasjonsdokumentet for NOARK 5 Tjenestegrensesnitt
  File 2017/1: Title of the test case file created 2017-03-18T23:49:32.103446
~/src//noark5-tester$

You can see here how the fonds (arkiv) and serie (arkivdel) only had one option, while the user need to choose which file (mappe) to use among the two created by the API tester. The archive-pdf tool can be found in the git repository for the API tester.

In the project, I have been mostly working on the API tester so far, while getting to know the code base. The API tester currently use the HATEOAS links to traverse the entire exposed service API and verify that the exposed operations and objects match the specification, as well as trying to create objects holding metadata and uploading a simple XML file to store. The tester has proved very useful for finding flaws in our implementation, as well as flaws in the reference site and the specification.

The test document I uploaded is a summary of all the specification defects we have collected so far while implementing the web service. There are several unclear and conflicting parts of the specification, and we have started writing down the questions we get from implementing it. We use a format inspired by how The Austin Group collect defect reports for the POSIX standard with their instructions for the MANTIS defect tracker system, in lack of an official way to structure defect reports for Noark 5 (our first submitted defect report was a request for a procedure for submitting defect reports :).

The Nikita project is implemented using Java and Spring, and is fairly easy to get up and running using Docker containers for those that want to test the current code base. The API tester is implemented in Python.

A few days ago, we received the ruling from my day in court. The case in question is a challenge of the seizure of the DNS domain popcorn-time.no. The ruling simply did not mention most of our arguments, and seemed to take everything ØKOKRIM said at face value, ignoring our demonstration and explanations. But it is hard to tell for sure, as we still have not seen most of the documents in the case and thus were unprepared and unable to contradict several of the claims made in court by the opposition. We are considering an appeal, but it is partly a question of funding, as it is costing us quite a bit to pay for our lawyer. If you want to help, please donate to the NUUG defense fund.

The details of the case, as far as we know it, is available in Norwegian from the NUUG blog. This also include the ruling itself.

On Wednesday, I spent the entire day in court in Follo Tingrett representing the member association NUUG, alongside the member association EFN and the DNS registrar IMC, challenging the seizure of the DNS name popcorn-time.no. It was interesting to sit in a court of law for the first time in my life. Our team can be seen in the picture above: attorney Ola Tellesbø, EFN board member Tom Fredrik Blenning, IMC CEO Morten Emil Eriksen and NUUG board member Petter Reinholdtsen.

The case at hand is that the Norwegian National Authority for Investigation and Prosecution of Economic and Environmental Crime (aka Økokrim) decided on their own, to seize a DNS domain early last year, without following the official policy of the Norwegian DNS authority which require a court decision. The web site in question was a site covering Popcorn Time. And Popcorn Time is the name of a technology with both legal and illegal applications. Popcorn Time is a client combining searching a Bittorrent directory available on the Internet with downloading/distribute content via Bittorrent and playing the downloaded content on screen. It can be used illegally if it is used to distribute content against the will of the right holder, but it can also be used legally to play a lot of content, for example the millions of movies available from the Internet Archive or the collection available from Vodo. We created a video demonstrating legally use of Popcorn Time and played it in Court. It can of course be downloaded using Bittorrent.

I did not quite know what to expect from a day in court. The government held on to their version of the story and we held on to ours, and I hope the judge is able to make sense of it all. We will know in two weeks time. Unfortunately I do not have high hopes, as the Government have the upper hand here with more knowledge about the case, better training in handling criminal law and in general higher standing in the courts than fairly unknown DNS registrar and member associations. It is expensive to be right also in Norway. So far the case have cost more than NOK 70 000,-. To help fund the case, NUUG and EFN have asked for donations, and managed to collect around NOK 25 000,- so far. Given the presentation from the Government, I expect the government to appeal if the case go our way. And if the case do not go our way, I hope we have enough funding to appeal.

From the other side came two people from Økokrim. On the benches, appearing to be part of the group from the government were two people from the Simonsen Vogt Wiik lawyer office, and three others I am not quite sure who was. Økokrim had proposed to present two witnesses from The Motion Picture Association, but this was rejected because they did not speak Norwegian and it was a bit late to bring in a translator, but perhaps the two from MPA were present anyway. All seven appeared to know each other. Good to see the case is take seriously.

If you, like me, believe the courts should be involved before a DNS domain is hijacked by the government, or you believe the Popcorn Time technology have a lot of useful and legal applications, I suggest you too donate to the NUUG defense fund. Both Bitcoin and bank transfer are available. If NUUG get more than we need for the legal action (very unlikely), the rest will be spend promoting free software, open standards and unix-like operating systems in Norway, so no matter what happens the money will be put to good use.

If you want to lean more about the case, I recommend you check out the blog posts from NUUG covering the case. They cover the legal arguments on both sides.

I just donated to the NUUG defence "fond" to fund the effort in Norway to get the seizure of the news site popcorn-time.no tested in court. I hope everyone that agree with me will do the same.

Would you be worried if you knew the police in your country could hijack DNS domains of news sites covering free software system without talking to a judge first? I am. What if the free software system combined search engine lookups, bittorrent downloads and video playout and was called Popcorn Time? Would that affect your view? It still make me worried.

In March 2016, the Norwegian police seized (as in forced NORID to change the IP address pointed to by it to one controlled by the police) the DNS domain popcorn-time.no, without any supervision from the courts. I did not know about the web site back then, and assumed the courts had been involved, and was very surprised when I discovered that the police had hijacked the DNS domain without asking a judge for permission first. I was even more surprised when I had a look at the web site content on the Internet Archive, and only found news coverage about Popcorn Time, not any material published without the right holders permissions.

The seizure was widely covered in the Norwegian press (see for example Hegnar Online and ITavisen and NRK), at first due to the press release sent out by Økokrim, but then based on protests from the law professor Olav Torvund and lawyer Jon Wessel-Aas. It even got some coverage on TorrentFreak.

I wrote about the case a month ago, when the Norwegian Unix User Group (NUUG), where I am an active member, decided to ask the courts to test this seizure. The request was denied, but NUUG and its co-requestor EFN have not given up, and now they are rallying for support to get the seizure legally challenged. They accept both bank and Bitcoin transfer for those that want to support the request.

If you as me believe news sites about free software should not be censored, even if the free software have both legal and illegal applications, and that DNS hijacking should be tested by the courts, I suggest you show your support by donating to NUUG.

It is days like today I am really happy to be a member of the Norwegian Unix User group, a member association for those of us believing in free software, open standards and unix-like operating systems. NUUG announced today it will try to bring the seizure of the DNS domain popcorn-time.no as unlawful, to stand up for the principle that writing about a controversial topic is not infringing copyrights, and censuring web pages by hijacking DNS domain should be decided by the courts, not the police. The DNS domain was seized by the Norwegian National Authority for Investigation and Prosecution of Economic and Environmental Crime a month ago. I hope this bring more paying members to NUUG to give the association the financial muscle needed to bring this case as far as it must go to stop this kind of DNS hijacking.

I first got to know I.F. Stone when I came across an article by Jon Schwarz on The Intercept about his extraordinary contribution to investigative journalism in USA. The article is about a new documentary in two parts (part one is 12 minutes and part two is 30 minutes), and I found both truly fascinating. It is amazing what he was able to find by digging up public sources and government papers. He documented lots of government abuse and cover ups, and I find his weekly news letters inspiring to read even today.

All governments are run by liars and nothing they say should be believed.
- I. F. Stone

His starting point was that reporters should not assume governments and corporations are telling the truth, but verify all their claims as much as possible. I wonder how many Norwegian reporters can be said to follow the principles of I. F. Stone. They are definitely in short supply. If you, like me half a year ago, have never heard of him, check him out.

For litt mer enn et år siden laget jeg litt statistikk for 2013 og 2014 basert på Offentlig elektronisk postjournal (OEP). Tallene finnes i tre bloggposter, en over hvem som er mest hemmelighetsfulle, en annen med hvor mye som mangler og en om hvor stor andel dokumenter som journalføres mer enn 180 dager etter dokumentdato. Jeg synes det er interessant å se hvordan det utvikler seg over tid, så her er tallene for 2015 og 2014. 2014-tallene bør være de samme som sist, men kan ha litt avvik på grunn av endringer/korreksjoner gjort i OEP. Denne gangen har jeg samlet alle tallene i samme bloggpost.

Først kommer statistikken over antall dokumenter som er registrert unntatt offentligheten i OEP. Merk at klassifiseringen i OEP er foreløpig, slik at en kan få innsyn i dokumenter merket unntatt offentlighet når en spør, etter nærmere vurdering. Det er dermed ikke gitt at prosentsatsen representerer hvor mange dokumenter som ville blitt holdt tilbake på forespørsel.

Interessant å se hvordan Utenriksdepartementet tilsynelatende er blitt ekstremt mer hemmelighetsfull på tre år. I 2015 var 99,8% av 71409 dokumenter merket som unntatt offentlighet, mens i 2014 var det 44,3% av 65121 og og i 2013 var det bare 12,1% av 67828. Lurer på hva som har skjedd. (Oppdatering 13:40: Dette er en teknisk feil i databasen, da UD har begynt å legge inn '-' der det ikke er unntak, mens det tidligere var et tomt felt. Skal lage ny statistikk, men det tar noen timer å lage ny tabell. Oppdatering 15:30: Ny tabell på plass, mer forklaring nederst i teksten.)

Dernest kommer statistikken over hvor mange saksnummer og dokumenter som ikke finnes i OEP (dvs. hull i saksnummer- og dokumentnummerserien). Se tidligere omtalte bloggpost for å forstå hvordan slike hull kan oppstå uten at det er noe galt eller mistenkelig med det.

Til sist er statistikken over hvor stor andel av utgående, inngående, og andre dokumenter som blir journalført mer enn 180 dager etter dokumentets dato, dvs. hvor stor andel som blir journalført ekstremt sent for utgående og interne dokumenter, mens det for innkommende like gjerne kan være at det tok lang tid før de ble mottatt.

Jeg lurer virkelig på hvordan så mange i det offentlige klarer å ikke journalføre utgående dokumenter med en gang de gjøres ferdig. Er det manglende opplæring, vanskelige systemer, vond vilje eller noe helt annet som er årsaken? Det hadde vært interessant å finne ut om det var noen fellestrekk for dokumenter som ikke blir journalført før det er gått et halvt år.

Oppdatering 2016-04-07: En nærmere undersøkelse av OEP-oppføringene til Utenriksdepartementet viste at det var en teknisk feil i måten jeg laget statistikken, der alle oppføringer med '-' i unntaksgrunnlagsfeltet ble talt opp som unntatt offentlighet. Det var UD ikke alene om. Det viste seg å gjelde Barne-, likestillings- og inkluderingsdepartementet (4), Helse- og omsorgsdepartementet (3525), Landbruks- og matdepartementet (1753), Nærings- og fiskeridepartementet (11780), Nærings- og handelsdepartementet (7), Nærings- og handelsdepartementet (frem til 31.12.13) (10417) og Utenriksdepartementet (78798) også. Antall påvirkede oppføringer står i parentes. Jeg har fikset problemet og oppdatert tabellen for hemmelighold over. Oppføringene for Nærings- og handelsdepartementet, Landbruks- og matdepartementet, Utenriksdepartementet og Helse- og omsorgsdepartementet fikk ny plassering i lista.

Jeg blogget for noen dager siden hva jeg har klart å finne ut så langt om en redegjørelse med tittelen «Internet Governance og påvirkning på nasjonal sikkerhet» fra et møte «holdt i Pentagon for et avgrenset utvalg av NATO-nasjoner, hvor arrangør ikke hadde til hensikt å gjøre innholdet offentlig kjent». Innsynssaken er påklaget til Sivilombudsmannen, og her er utvekslingen med Sivilombudsmannen så langt. Det startet med en innsynshenvendelse til Samferdselsdepartementet (sak 2012/914 - kopi av noen av dokumenter på Mimes brønn). Deretter gikk det slag i slag. Se den overnevnte bloggposten for detaljer.

Da det virket rart at Utenriksdepartementet og Samferdselsdepartementet ikke er enige i hvorfor dokumentet skulle unndras offentlighet, og at et dokument relevant for en tre år gammel forhandling fortsatt skulle holdes hemmelig for å ikke avsløre Norges forhandlingsposisjon, klaget vi saken inn for Sivilombudsmannen. Foreningen NUUG sa seg villig til å dekke advokatkostnader til å formulere klagen, og advokat Ola Tellesbø tok på seg oppgaven. Her er klagen vi sendte for noen uker siden:

Klage til Sivilombudsmannen

Norsk Unix User Group, heretter NUUG, klager på vegne av sitt medlem Petter Reinholdtsen over manglende innsyn. Det klages også over manglende journalføring hos den norske FN-delegasjonen i Geneve.

Om NUUG og offentlighet

Herværende sak er av stor prinsipiell verdi for NUUG. NUUG er en ikke-kommersiell forening som arbeider for utbredelse av UNIX-lignende systemer, fri programvare og åpne standarder i Norge. Foreningen har 306 medlemmer og driver tjenestene FiksGataMi og Mimes Brønn.

Tjenesten Mimes Brønn er en innsynstjeneste hvor NUUGs medlemmer og allmennheten kan spørre om innsyn i statens og kommunens dokumenter. Mimes Brønn er basert på programvare fra MySociety i England og er tilpasset på dugnad av NUUGs medlemmer. Noen av medlemmene har benyttet tjenesten til selv å be om innsyn i dokumenter. Vi i NUUG holder på med dette først og fremst fordi vi syntes det er gøy å benytte fri programvare til samfunnsnyttige formål. Dessuten ønsker NUUG å støtte opp under allmennhetens innsynsrett etter Grunnlovens §100 og formålet til offentlighetsloven. NUUG ønsker å legge til rette for en mer åpen, tilgjengelig og vennlig forvaltning.

Innsynshenvendelser flest imøtekommes tilfredsstillende. Enkelte andre henvendelser har avstedkommet mindre imøtekommende svar og en mer lukket forvaltning. En av sakene som har vist seg vanskelig og uoversiktlig, er NUUG-medlem Petter Reinholdtsens langvarige søk etter opplysninger om dokumenter i en sak som berører 'Interent Governance'. Siden NUUG mener behandlingen strider med formålet til offentlighetsloven, og svekker tilliten til forvaltningen, trer NUUG inn i sitt medlems krav om rett til innsyn i opplysninger i disse dokumentene. Saken er av stor prinsipiell verdi for NUUG fordi NUUG driver Mimes Brønn og medlemmene ønsker informasjon om hvordan Norge forsøker å påvirke reguleringen av Internettet.

NUUG ønsker at flere borgere engasjerer seg i de tingene våre utøvende myndigheter foretar seg og er bekymret for at saksbehandling som dette kan svekke den demokratisk deltakelsen.

Det legges til at NUUG sitter på betydelig kompetanse på 'Internett Governance' med gode forutsetninger til å bidra konstruktivt. Det er viktig at staten ikke begrenser innsyn i Internettets fellesanliggende utover det loven hjemler samt aktivt praktiserer meroffentlighet på feltet.

Sakens bakgrunn

I 2012 ba Petter Reinholdtsen om innsyn i et brev datert 22.5.2012 med tittelen 'Internet Governance og påvirkning på nasjonal sikkerhet'. Det ble gitt avslag med begrunnelse i pågående forhandlinger.

Tre år etterpå begjærte Reinholdtsen på ny innsyn, henholdsvis av 10.6.2015 til Utenriksdepartementet (UD) som avsender av brevet og av 21.6.2015 til Samferdselsdepartementet (SD) som mottaker.

UD avslo innsyn 'med henvisning til offentleglova § 20 1. ledd litra b'. Som bevis for det tilbys:

Link 1: https://www.mimesbronn.no/request/brev_om_internet_governance_og_p

SD avslo innsyn 'med begrunnelse i offentleglova § 20, bokstav c'. Som bevis for det tilbys:

Link 2: https://www.mimesbronn.no/request/kopi_av_dokumenter_i_sak_2012914

Begge departementene vurderte merinnsyn.

Linkene viser at det er klaget. SD opprettholdt den 28.8.2015 avslaget med begrunnelse at dokumentet 'tilkjennegir posisjoner i de internasjonale forhandlingene om regulering av Internett. Dette er forhandlinger som pågår fremdeles i ulike internasjonale fora der Norge deltar.'

UD har ikke besvart klagen. Det ble purret 7.10.2015.

Det klages herved på avslagene. Det klages også over manglende begrunnelse for hvorfor SD og UD hver for seg har kommet til at meroffentlighet ikke kommer til anvendelse.

Klagen utvides til å omfatte at Norges FN-delegasjon i Geneve som stod som avsender til SD, ikke har journalført dokumentet i sin postjournal. Manglende journalføring forklarte UD 31.6.2015 med at 'siden delegasjonen kun var kopimottaker for dokumentet og videresending til Samferdselsdepartementet ikke inngikk som en del av intern saksbehandling er dokumentet ikke blitt journalført ved delegasjonen'. Det anføres at dette ikke er et tilstrekkelig grunnlag for ikke å journalføre dokumentet.

Dersom Sivilombudsmannen kommer fram til at innsyn ikke skal gis, ber vi om å få vurdert rett til innsyn i metainformasjon om når det aktuelle møtet i Pentagon var, saksnummer hos avsender, hvilke stater som deltok og navn på delegatene.

Rettslige anførsler

Avslagene er hjemlet i offentlighetslovens §20 som gjelder 'omsyn til Norges utanrikspolitiske interesser'. UD viser til bokstav b om rett til å avslå innsyn fordi opplysningene er gitt under forutsetning av hemmelighold. SD viser til bokstav c om rett til å avslå innsyn i opplysninger som gjelder norske forhandlingsposisjoner, forhandlingsstrategier eller liknende.

Offentlighetslovens §1 gir klare føringer for hvordan loven skal praktiseres:

'Formålet med lova er å leggje til rette for at offentleg verksemd er open og gjennomsiktig, for slik å styrkje informasjons- og ytringsfridommen, den demokratiske deltakinga, rettstryggleiken for den enkelte, tilliten til det offentlege og kontrollen frå ålmenta. Lova skal òg leggje til rette for vidarebruk av offentleg informasjon.'

Lovgiver har lagt til grunn at hensynene som er nevnt §1 skal tillegges vekt som tolkningsmoment og ved tolkningstvil, jf. Innst.O.nr.41 (2005-2006), punkt 2.2:

'Komiteen viser til at en formålsbestemmelse først og fremst har betydning som en programerklæring og målsetning for loven. Men komiteen vil fremheve at den også har en viktig betydning når det er tolkningstvil i forhold til andre bestemmelser i loven. Ved tvil om tolkning skal en prinsipielt sett falle ned på det som er mest i tråd med formålsparagrafen. Komiteen vil påpeke at man i forslaget til formålsbestemmelse mangler det viktigste og mest åpenbare formålet med loven, nemlig å skape tillit til forvaltningen.'

Unntaket i både bokstav b og c i §20 gjelder opplysninger, ikke for hele dokumenter. Med andre ord skal opplysningene det er grunnlag for å unnta, tas ut av dokumentet, mens resten av dokumentet skal frigis. Dette følger direkte av ordlyden, og er framhevet både i forarbeider og i Justis- og politidepartementets 'Rettleiar til offentleglova' (G-2009-419). Av veilederen framgår at unntak for opplysninger av hensyn til Norges utenrikspolitiske interesser, er 'presisert og snevra inn i den nye lova' sammenlignet med offentlighetsloven av 1970 (s.126).

Dette framgår også klart av Stortingets behandling av loven i Innst.O.nr.41 (2005-2006), jf. punkt 2.7 Unntak for å ivareta utanrikspolitiske interesser mv.:

'Komiteen er klar over at det på områder som har med utenrikspolitikk og andre avtaler av særlig nasjonal betydning, eksempelvis avtaler med andre land om utveksling av etterretningsinformasjon, er nødvendig med unntak av innsyn. Komiteen vil likevel påpeke at det samtidig skal vurderes om deler av informasjonen skal kunne gjøres tilgjengelig dersom dette ikke skader forholdet til andre land eller bryter avtaler om gjensidig fortrolighet. Komiteen vil begrunne dette med at åpenhet ofte er en forutsetning for befolkningens aksept og at det således er grunnlaget for tiltaket.

Komiteen vil derfor presisere at de nødvendige unntaksbestemmelser skal nyttes med varsomhet.'

UD viser til at brevet omhandler et møte i Pentagon med et avgrenset utvalg NATO-nasjoner der arrangør ikke hadde til hensikt å gjøre innholdet offentlig kjent, samt at innsyn kan gi redusert tilgang til lignende informasjon og slik ha skadevirkninger for norske utenrikspolitiske interesser. Den nevnte veilederen uttrykker imidlertid:

'Kravet om at unntak må vere påkravd, vil likevel i praksis føre til at det oftare ikkje vil vere høve til å gjere unntak der det ligg føre ein fast praksis enn der det gjeld ei folkerettsleg plikt til hemmeleghald (fyrste ledd bokstav a). Ei rekkje statar fører no ein meir open utanrikspolitikk. Dette påverkar internasjonal praksis. Jamvel om det framleis ligg føre ein internasjonal praksis på eit område, vil det dermed ikkje i alle tilfelle vere fare for skadeverknader dersom det blir gitt innsyn i opplysningar som er omfatta av ein slik praksis.' (s.132-133)

At unntaket må være påkrevd av hensyn til Norges utenrikspolitiske interesser setter et strengt vilkår for å unnta opplysninger innsyn. Ut fra ordlyden er det altså ikke nok at det er ønskelig eller mest hensiktsmessig. Justis- og politidepartementet forklarer det slik i veilederen:

'At unntak må vere «påkravd» inneber at det må eksistere ei verkeleg fare for at innsyn kan gje skadeverknader av eit visst omfang for norske utanrikspolitiske interesser. Fjerntliggjande og små farar for skadeverknader er ikkje tilstrekkeleg.' (s.128)

Det anføres at det ikke eksisterer en fare for skade dersom det gis innsyn.

Avslag begrunnet i bokstav c forutsetter at opplysningene gjelder norske forhandlinger, forhandlingsstrategier og lignende der innsyn vil kunne svekke Norges forhandlingsposisjon. Det følger av veilederen at unntaket som hovedregel kun gjelder fram til forhandlingene er avsluttet:

'Etter at forhandlingane er avslutta vil det vanlegvis ikkje lenger vere behov for å gjere unntak for opplysningar om forhandlingsposisjonar og liknande. Høvet til å gjere unntak etter fyrste ledd bokstav c gjeld difor i utgangspunktet berre inntil dei aktuelle forhandlingane er avslutta.' (s.133)

De aktuelle forhandlingene er avsluttet for tre år siden. Følgelig kan ikke dokumentet som det begjæres innsyn i, unntas offentlighet. SD viser imidlertid til at dokumentet 'tilkjennegir posisjoner' og til at forhandlinger om regulering av Internett fremdeles pågår 'i ulike internasjonale fora der Norge deltar'. Mot dette anføres at Norges posisjon ikke kan være ukjent for andre forhandlingspartnere og at den norske offentligheten har rett på å kjenne Norges posisjon. Dette får ekstra vekt ved at spesifikke posisjoner inntatt for tre år siden, vil være utdaterte og irrelevante for de forhandlingene som fortsatt pågår, mens de store linjene som fortsatt er relevante, er kjente posisjoner hos forhandlingspartnerne. Disse sistnevnte posisjonene er igjen av stor offentlig interesse. Dermed må SD falle tilbake på utgangspunktet om at unntaket ikke kommer til anvendelse fordi det er tre år siden de aktuelle forhandlingene ble avsluttet.

Subsidiært anføres at sistnevnte uansett må tillegges avgjørende vekt i vurderingen av meroffentlighet. Dette gjelder både i vurderingen opp mot bokstav b og c i §20. Uten å praktisere meroffentlighet kan ikke det offentlige rommet bidra med viktige innsikter vedrørende regulering av Internettet. Det vitenskapelige miljøet og andre fagfolk avspises i stedet med å ta nye reguleringer til etterretning. Internettet angår oss alle, og ikke bare statens sikkerhet, men alles sikkerhet mot å bli overvåket og mot at personopplysninger kommer på avveie. Den enkelte borger trenger i et velfungerende demokrati å kunne gjøre seg kjent med hva som er Norges posisjoner i reguleringen av Internettet. Offentligheten har således en særskilt interesse i at det praktiseres meroffentlighet i saker som vedgår 'Internet Governance' og sikkerhet.

Det er for øvrig påtakelig at UD og SD begrunner avslaget ulikt. Begrunnelsene framstår dermed som tilfeldige og vikarierende. Hvorfor vektlegger ikke SD at det er forutsatt at møtet ikke skulle være offentlig? Er det slik å forstå at SD mener at dette ikke er tilfellet? Hvorfor vektlegger ikke UD at Norges posisjoner med tanke på framtidige forhandlinger vil bli avdekket? Mener UD at dette ikke er tilfellet?

Det anføres at de ulike begrunnelsene viser at begjæringen om innsyn ikke har vært grundig vurdert, og dermed enda mindre hvilke opplysninger som i tilfellet må unntas offentlighet. I stedet antyder de ulike begrunnelsene at UD eller SD, eller begge, summarisk avslår innsyn basert på overflatiske kriterier uten en konkret rettslig vurdering av hvilke opplysninger som det kan gjøres unntak for. Dette blir særlig framtredende tatt i betraktning at dokumentet er tre år gammelt og spesifikke posisjoner i det aktuelle møtet vil være utdaterte mens generelle posisjoner vil være av største allmenne interesse. SD kan ikke bli hørt med, jf. det endelige avslaget av 28.8.2105, at i 'denne saken unntas hele dokumentet, fordi hele dokumentet inneholder informasjon som oppfyller unntaksvilkårene' i §20.

Likeledes for unntak etter bokstav b, selv om arrangøren vil at møtet skulle unntas offentlighet, må UD vurdere hvilke opplysninger som er påkrevd unntatt ut fra om innsyn vil utgjøre en fare for skadevirkninger av et visst omfang for norske utenrikspolitiske interesser. Dersom UD ikke gjør det, vil enhver forutsetning om ikke-offentlighet innebære at alle dokumenter i sin helhet alltid unntas offentlighet. Dette vil være i direkte strid med bokstav b i §20 som ikke gir en generell adgang til å holde dokumenter unna offentligheten. Dette har lovgiver allerede vurdert og konkret tatt stilling til og, som påpekt, gir bokstav b kun unntak for opplysninger, ikke for dokumenter. Til dette anfører vi at det er direkte feil når det i den omtalte veilederen står at delvis 'innsyn vil truleg i praksis oftast vere aktuelt når det blir gjort unntak etter § 20 fyrste ledd bokstav c' (s. 134). Det er ikke holdepunkter for en slik tolkning i forarbeidene. Videre bemerker denne siden at verken UD eller SD har påberopt seg at 'det vil vere urimeleg arbeidskrevjande [...] å skilje' ut deler av dokumentet.

Det anføres avslutningsvis at en lettvin vurdering og avslag av innsynsbegjæringen understreker at departementene ikke kan ha vurdert meroffentlighet slik §11 forutsetter.

Klagesaken fikk saksnummer 2015/2866 hos Sivilombudsmannen, og foreløpig svar fulgte noen dager etter at vi sendte inn klagen:

FORELØPIG SVAR - SAK OM INNSYN I BREV OM «INTERNET GOVERNANCE»

Ombudsmannen har mottatt ditt brev 17. september 2015 med vedlegg på vegne av Norsk Unix User Group, som igjen representerer sitt medlem Petter Reinholdtsen. Brevet ble mottatt her 14. oktober 2015.

Saken gjelder for det første spørsmål om rett til innsyn hos Utenriksdepartementet og Samferdselsdepartementet i et dokument med tittelen «Internet Governance og påvirkning på nasjonal sikkerhet». Det klages på Utenriksdepartementets avslag på innsyn i dokumentet 23. juli 2015 og Samferdselsdepartementets avslag på innsyn, som etter klage ble opprettholdt 28. august 2015. Klagen gjelder også manglende journalføring hos FN-delegasjonen i Genève.

Samferdselsdepartementet er i brev herfra i dag bedt om å oversendte sakens dokumenter, se vedlagte kopi. Når dokumentene er mottatt, vil ombudsmannen vurdere om den delen av klagen som gjelder Samferdselsdepartementets behandling av innsynsbegjæringen gir grunn til videre behandling.

Det fremgår av klagen at Reinholdtsen klaget til Utenriksdepartementet på departementets avslag, men at han ikke har fått svar, og at han purret departementet 7. oktober 2015. Det er herfra tatt kontakt med Utenriksdepartementet Birger Veum opplyste til seniorrådgiver Elisabeth Fougner, at svaret på grunn av en intern misforståelse ikke er blitt sendt ut, men at Reinholdtsen nå vil få svar i løpet av få dager.

Ombudsmannens kontroll med forvaltningen skal være etterfølgende. Det vil si at en sak ikke kan behandles før den er endelig avgjort i forvaltningen. I første omgang må Norsk Unix User Group derfor avvente Utenriksdepartementet behandling av klagen. Når departementet har gitt et svar, kan det eventuelt rettes en ny klage hit om saken. Dersom Reinholdtsen ikke snarlig mottar svar fra departementet kan det også sendes en ny klage hit om dette.

Prinsippet om at ombudsmannens kontroll skal være etterfølgende tilsier også at Riksarkivet, som har tilsynssvar for arkivarbeid i offentlige organer, bør ta stilling til klagen på manglende journalføring hos den norske FN-delegasjonen i Genève før spørsmålet behandles her. Norsk Unix User Group må derfor i første omgang ta denne delen av klagen opp med Riksarkivet. Når Riksarkivet har tatt endelig stilling til Journalføringsspørsmålet, kan det eventuelt rettes en ny klage hit om dette spørsmålet.

Det vil bli gikk tilbakemelding i saken om Samferdselsdepartementets avslag på innsyn innen 2 - 4 uker.

Henvendelsen fra Sivilombudsmannen til Samferdselsdepartementet ble gitt samme saksnummer som opprinnelig avslag (sak 2015/3192), og jeg ser fra Offentlig Elektronisk Postjournal (OEP) at Samferdselsdepartementet har svart Sivilombudsmannen 2015-10-29. Venter spent på hva de kommer frem til der.

Vi ble bedt om å ta opp manglende journalføring først med Riksarkivet, så der sendte jeg inn et spørsmål om innsyn i praksis og klage på manglende journalføring via Mimes brønn, og har fått beskjed om at denne har fått saksnummer 2015/29039. Den saken har ikke dukket opp på OEP i skrivende stund, men jeg antar den kommer inn om noen dager.

Samtidig som Sivilombudsmannen sendte oss det foreløpige svaret om avslaget fra Samferdselsdepartementet kom Utenriksdepartementets svar der de opprettholdt avslaget på innsyn. Dette sendte vi beskjed om til Sivilombudsmannen like etter:

Vi viser til Sivilombudsmannens foreløpige svar av 22.10.2015.

Utenriksdepartementet opprettholdt den 22.10.2015 sitt avslag, se siste postering i linken:

<https://www.mimesbronn.no/request/brev_om_internet_governance_og_p>

Originaldokumentet fra Utenriksdepartementet kan lastes ned fra den samme posteringen.

Saken er dermed endelig avgjort i forvaltningen. Vi ber Sivilombudsmannen om å ta opp igjen vår klage til fortsatt behandling.

Dette brevet ble tilordnet ny sak 2015/3077 hos Sivilombudsmannen, som så vidt jeg kan forstå gjelder klagen mot Utenriksdepartementet. Postjournalen hos Sivilombudsmannen har kun det ene dokumentet så langt, og jeg fant ingenting hos Utenriksdepartementet fra Sivilombudsmannen i OEP. Regner med at det dukker opp mer om noen dager, når Sivilombudsmannen har bedt om mer informasjon.

Jeg venter spent på fortsettelsen.

Oppdatering 2015-11-17: Innsynshenvendelsen og klagen har fått saksnummer 2015/9816 hos Utenriksdepartementet.

In Norway, all government offices are required by law to keep a list of every document or letter arriving and leaving their offices. Internal notes should also be documented. The document list (called a mail journal - "postjournal" in Norwegian) is public information and thanks to the Norwegian Freedom of Information Act (Offentleglova) the mail journal is available for everyone. Most offices even publish the mail journal on their web pages, as PDFs or tables in web pages. The state-level offices even have a shared web based search service (called Offentlig Elektronisk Postjournal - OEP) to make it possible to search the entries in the list. Not all journal entries show up on OEP, and the search service is hard to use, but OEP does make it easier to find at least some interesting journal entries .

In 2012 I came across a document in the mail journal for the Norwegian Ministry of Transport and Communications on OEP that piqued my interest. The title of the document was "Internet Governance and how it affects national security" (Norwegian: "Internet Governance og påvirkning på nasjonal sikkerhet"). The document date was 2012-05-22, and it was said to be sent from the "Permanent Mission of Norway to the United Nations". I asked for a copy, but my request was rejected with a reference to a legal clause said to authorize them to reject it (offentleglova § 20, letter c) and an explanation that the document was exempt because of foreign policy interests as it contained information related to the Norwegian negotiating position, negotiating strategies or similar. I was told the information in the document related to the ongoing negotiation in the International Telecommunications Union (ITU). The explanation made sense to me in early January 2013, as a ITU conference in Dubay discussing Internet Governance (World Conference on International Telecommunications - WCIT-12) had just ended, reportedly in chaos when USA walked out of the negotiations and 25 countries including Norway refused to sign the new treaty. It seemed reasonable to believe talks were still going on a few weeks later. Norway was represented at the ITU meeting by two authorities, the Norwegian Communications Authority and the Ministry of Transport and Communications. This might be the reason the letter was sent to the ministry. As I was unable to find the document in the mail journal of any Norwegian UN mission, I asked the ministry who had sent the document to the ministry, and was told that it was the Deputy Permanent Representative with the Permanent Mission of Norway in Geneva.

Three years later, I was still curious about the content of that document, and again asked for a copy, believing the negotiation was over now. This time I asked both the Ministry of Transport and Communications as the receiver and asked the Permanent Mission of Norway in Geneva as the sender for a copy, to see if they both agreed that it should be withheld from the public. The ministry upheld its rejection quoting the same law reference as before, while the permanent mission rejected it quoting a different clause (offentleglova § 20 letter b), claiming that they were required to keep the content of the document from the public because it contained information given to Norway with the expressed or implied expectation that the information should not be made public. I asked the permanent mission for an explanation, and was told that the document contained an account from a meeting held in the Pentagon for a limited group of NATO nations where the organiser of the meeting did not intend the content of the meeting to be publicly known. They explained that giving me a copy might cause Norway to not get access to similar information in the future and thus hurt the future foreign interests of Norway. They also explained that the Permanent Mission of Norway in Geneva was not the author of the document, they only got a copy of it, and because of this had not listed it in their mail journal.

Armed with this knowledge I asked the Ministry to reconsider and asked who was the author of the document, now realising that it was not same as the "sender" according to Ministry of Transport and Communications. The ministry upheld its rejection but told me the name of the author of the document. According to a government report the author was with the Permanent Mission of Norway in New York a bit more than a year later (2014-09-22), so I guessed that might be the office responsible for writing and sending the report initially and asked them for a copy but I was obviously wrong as I was told that the document was unknown to them and that the author did not work there when the document was written. Next, I asked the Permanent Mission of Norway in Geneva and the Foreign Ministry to reconsider and at least tell me who sent the document to Deputy Permanent Representative with the Permanent Mission of Norway in Geneva. The Foreign Ministry also upheld its rejection, but told me that the person sending the document to Permanent Mission of Norway in Geneva was the defence attaché with the Norwegian Embassy in Washington. I do not know if this is the same person as the author of the document.

If I understand the situation correctly, someone capable of inviting selected NATO nations to a meeting in Pentagon organised a meeting where someone representing the Norwegian defence attaché in Washington attended, and the account from this meeting is interpreted by the Ministry of Transport and Communications to expose Norways negotiating position, negotiating strategies and similar regarding the ITU negotiations on Internet Governance. It is truly amazing what can be derived from mere meta-data.

I wonder which NATO countries besides Norway attended this meeting? And what exactly was said and done at the meeting? Anyone know?

Jeg lot meg fascinere av en artikkel i Aftenposten der det fortelles at «over 600 telefoner som benyttes av stortingsrepresentanter, rådgivere og ansatte på Stortinget, kan «fjernstyres» ved hjelp av programvaren Airwatch, et såkalte MDM-program (Mobile Device Managment)». Det hele bagatelliseres av Stortingets IT-stab, men det er i hovedsak på grunn av at journalisten ikke stiller de relevante spørsmålene. For meg er det relevante spørsmålet hvem som har lovlig tilgang (i henhold til lokal lovgiving, dvs. i hvert fall i Norge, Sverige, UK og USA) til informasjon om og på telefonene, og hvor enkelt det er å skaffe seg tilgang til hvor mobilene befinner seg og informasjon som befinner seg på telefonene ved hjelp av utro tjenere, trusler, innbrudd og andre ulovlige metoder.

Bruken av AirWatch betyr i realiteten at USAs etteretning og politimyndigheter har full tilgang til stortingets mobiltelefoner, inkludert posisjon og innhold, takket være FISAAA-loven og "National Security Letters" og det enkle faktum at selskapet AirWatch er kontrollert av et selskap i USA. I tillegg er det kjent at flere lands etterretningstjenester kan lytte på trafikken når den passerer landegrensene.

Jeg har bedt om mer informasjon fra Stortinget om bruken av AirWatch via Mimes brønn så får vi se hva de har å fortelle om saken. Fant ingenting om 'airwatch' i postjournalen til Stortinget, så jeg trenger hjelp før jeg kan be om innsyn i konkrete dokumenter.

Oppdatering 2015-10-07: Jeg er blitt spurt hvorfor jeg antar at AirWatch-agenten rapporterer til USA og ikke direkte til Stortingets egen infrastruktur. Det stemmer at det er teknisk mulig å sette opp mobiltelefonene til å rapportere til datamaskiner som eies av Stortinget. Jeg antar det rapporteres til AirWatch sine sentrale tjenester basert på det jeg leste fra beskrivelsen av Mobile Device Management på AirWatch sine egne nettsider, koblet med at det brukes en standard app som kan hentes fra "app-butikkene" for å få tilgang. Enten må app-en settes opp individuelt hos Stortinget, eller så får den beskjed fra AirWatch i USA om hvor den skal koble seg opp. I det første tilfellet vil den ikke rapportere direkte til USA, men til programvare utviklet av AirWatch som kjører på en maskin under Stortingets kontroll. Det er litt bedre, men fortsatt vil det være umulig for Stortinget å være sikker på hva programvaren som tar imot forbindelser gjør. Jeg ser fra beskrivelsen av Enterprice Integration hos AirWatch at det er mulig å ha lokal installasjon, og håper innsynsforespørsler mot Stortinget kan fortelle mer om hvordan ting konkret fungerer der.

I går fikk vi endelig lansert en norsk version av mySocietys WhatDoTheyKnow. Tjenesten heter Mimes brønn, og ble annonsert av NUUG via blogg, epost og twitter til NUUG-assosierte personer. Det har tatt noen år, men de siste dagene fikk vi endelig tid til å få på plass de siste bitene. Vi er to, Gorm og meg selv, som har vært primus motor for det hele, men vi har fått hjelp med oversettelser og oppsett fra mange flere. Jeg vil si tusen takk til hver og en av dem, og er veldig fornøyd med at vi klarte å få tjenesten opp å kjøre før ferietiden slo inn for fullt.

Vi er usikker på hvor mye belastning den virtuelle maskinen der tjenesten kjører klarer, så vi har lansert litt i det stille og ikke til for mange folk for å se hvordan maskinen klarer seg over sommeren, før vi går mer aktivt ut og annonserer til høsten. Ta en titt, og se om du kanskje har et spørsmål til det offentlige som er egnet å sende inn via Mimes brønn.

Hvis du lurer på hva i alle dager en slik tjenestes kan brukes til, anbefaler jeg deg å se TED-foredraget til Heather Brook om hvordan hun brukte WhatDoTheyKnow til å lære hvordan offentlige midler ble misbrukt. Det er en inspirerende historie.

I en global verden med eierskap på tvers, trengs det informasjon om hvem som har kontrollen i selskaper og bedrifter. Og for å få tilgang til slik informasjon for alle som ønsker å analysere eierskap, holder med ikke med nasjonale databaser over eierskap, det må globale samledatabaser med åpne data til. Heldigvis finnes det en internasjonal bevegelse for å gjøre selskapsinformasjon for alle land offentlig tilgjengelig. En slik database heter OpenCorporates, der informasjonen er gratis tilgjengelig med en "del på samme vilkår"-lisens. De samler inn selskapsinformasjon, eierskap, konsesjonstildelinger og lignende. De manglet ganske mye for Norge, da bruksvilkårene til Norsk offentlig informasjon i stor grad blokkerer OpenCorporates fra å samle den inn.

Men jeg er jo involvert i Frikanalen, som har TV-konsesjon, og tenkte det kunne være fint om informasjon om alle mediakonsesjoner var tilgjengelig i OpenCorporates, så jeg sendte avgårde følgende spørsmål til Medietilsynet 2015-06-22:

Hei. Finnes det en oversikt over enhetene som Mediatilsynet fører tilsyn med som åpne data? Jeg lette etter den på <URL:http://data.norge.no/> og <URL:http://hotell.difi.no/> uten å finne noe der, og fant heller ikke noe under <URL:http://www.medietilsynet.no/>.

Jeg tenker på alle som har fått kringkastingskonsesjon og alle som er omtalt under <URL:http://www.medietilsynet.no/mediebildet/>.

Jeg skulle gjerne hatt dette maskinlesbart, og inkludert organisasjonsnummer og hva slags forhold mediatilsynet har til organisasjonene. Tanken er å importere det i <URL:https://opencorporates.com/> for analyse, så det bør ikke ha bruksbegresninger som gjør dette umulig.

To dager senere fikk jeg svar, med de datasettene de hadde tilgjengelig. Svaret fra Hanne Sekkelsten hos Medietilsynet var informativt og imøtekommende.

Vi viser til din e-post av 22. juni, der du ber om å få tilsendt oversikter over aktører Medietilsynet fører tilsyn med.

Medietilsynet fører tilsyn med kringkastere og audiovisuelle bestillingstjenester som omfattes av kringkastingsloven, og med eierskap i aviser, fjernsyn radio og elektroniske medier etter medieeierskapsloven. I tillegg vil Medietilsynet etter at beskyttelsesloven trer i kraft fra 1. juli ha tilsyn med en rekke nye aktører. Nærmere informasjon om den nye loven finnes på Medietilsynets nettsted, her: http://www.medietilsynet.no/mediebransjen/bildeprogramloven/ . Vi har ikke utarbeidet oversikter over alle aktørene, men vi sender deg her de listene vi har utarbeidet, hentet fra våre databaser. Vi har dessverre ikke ferdige rapporter som inneholder organisasjonsnummer. Dersom du ønsker flere opplysninger ber vi om at du tar kontakt med oss slik at vi kan finne ut av hvilke opplysninger du trenger, og hvilke vi kan fremskaffe.

Vedlagt følger:

• Konsesjoner - lokalradio FM pr. 31.12.2014 [PDF (original)]
• Konsesjoner - lokalfjernsyn i det digitale bakkenettet for fjernsyn, pr. mars 2015 [DOCX (original), PDF]
• Konsesjoner - DAB-radio, status mars 2015 [XPS (original), PDF]
• Registreringspliktige kringkastere - status mars 2015: [XPS (original), PDF]
  • Kabelsendt fjernsyn
  • Satellittsendt fjernsyn
  • Nett-tv
  • Kabelsendt radio
  • Satellittsendt radio
  • Nett-radio

Vi må ta forbehold om at det kan være enkelte feil i oversiktene siden disse ikke er oppdaterte pr. dags dato. Vi vil foreta nye oppdateringer i august.

Med hilsen

Hanne Nistad Sekkelsten
Seniorrådgiver | Senior Legal Adviser
Medietilsynet | Norwegian Media Authority
A: Nygata 4, NO-1607 Fredrikstad
T: [telefonnummer fjernet]
E: [adresse fjernet] | W: www.medietilsynet.no

Desverre er formatene for ustrukturerte til maskinell behandling og mangler endel informasjon, men det er gode oversikter over hvem Medietilsynet fører tilsyn med. Filene er på formatene PDF, XPS (XML-basert PDF-lignende format fra Microsoft) og DOCX, så det vil være en stor jobb å strukturere informasjonen på en måte som kan importeres i OpenCorporates. Svaret er ikke i tråd med Forskrift om IT-standarder i offentlig forvaltning som sier epostvedlegg skal sendes som PDF, så jeg har gjorde PDF-utgaver av XPS og DOCX-utgavene tilgjengelig for å gjøre det enklere for alle å se innholdet.

It is a bit work to figure out the ownership structure of companies in Norway. The information is publicly available, but one need to recursively look up ownership for all owners to figure out the complete ownership graph of a given set of companies. To save me the work in the future, I wrote a script to do this automatically, outputting the ownership structure using the Graphviz/dotty format. The data source is web scraping from Proff, because I failed to find a useful source directly from the official keepers of the ownership data, Brønnøysundsregistrene.

To get an ownership graph for a set of companies, fetch the code from git and run it using the organisation number. I'm using the Norwegian newspaper Dagbladet as an example here, as its ownership structure is very simple:

% time ./bin/eierskap-dotty 958033540 > dagbladet.dot

real    0m2.841s
user    0m0.184s
sys     0m0.036s
%

The script accept several organisation numbers on the command line, allowing a cluster of companies to be graphed in the same image. The resulting dot file for the example above look like this. The edges are labeled with the ownership percentage, and the nodes uses the organisation number as their name and the name as the label:

digraph ownership {
rankdir = LR;
"Aller Holding A/s" -> "910119877" [label="100%"]
"910119877" -> "998689015" [label="100%"]
"998689015" -> "958033540" [label="99%"]
"974530600" -> "958033540" [label="1%"]
"958033540" [label="AS DAGBLADET"]
"998689015" [label="Berner Media Holding AS"]
"974530600" [label="Dagbladets Stiftelse"]
"910119877" [label="Aller Media AS"]
}

To view the ownership graph, run "dotty dagbladet.dot" or convert it to a PNG using "dot -T png dagbladet.dot > dagbladet.png". The result can be seen below:

Note that I suspect the "Aller Holding A/S" entry to be incorrect data in the official ownership register, as that name is not registered in the official company register for Norway. The ownership register is sensitive to typos and there seem to be no strict checking of the ownership links.

Let me know if you improve the script or find better data sources. The code is licensed according to GPL 2 or newer.

Update 2015-06-15: Since the initial post I've been told that "Aller Holding A/S" is a Danish company, which explain why it did not have a Norwegian organisation number. I've also been told that there is a web services API available from Brønnøysundsregistrene, for those willing to accept the terms or pay the price.

I am happy to let you all know that I'm going to the Open Source Developers' Conference Nordic 2015!

It take place Friday 8th to Sunday 10th of May in Oslo next to where I work, and I finally got around to submitting a talk proposal for it (dead link for most people until the talk is accepted). As part of my involvement with the Norwegian Unix User Group member association I have been slightly involved in the planning of this conference for a while now, with a focus on organising a Civic Hacking Hackathon with our friends over at mySociety and Holder de ord. This part is named the 'My Society' track in the program. There is still space for more talks and participants. I hope to see you there.

Check out the talks submitted and accepted so far.

En ting jeg har lurt på når det gjelder offentlige postjournaler, er hvor stor andel av det som ligger i de interne databasene kommer ikke med i postjournalen. Dette er det mulig å finne ut basert på det som ligger i postjournalen. For å forstå hva jeg mener, trengs det litt bakgrunnsinformasjon. I henhold til NOARK-standarden for norske offentlige arkiv skal enhver sak ha et årstall og et løpenummer, og ethvert dokument i saken skal gis et dokument-løpenummer. Det vil si at en ender opp med dokument-ID som ser ut som ÅÅÅÅ/SAKNR-DOKNR, f.eks. 2014/2-1 eller 2014/12312-14. Mange oppgir kun tosifret årstall, men prinsippet er det samme. Så vidt jeg vet skal saksnummer og dokumentnummer tildeles løpende og i stigende rekkefølge. Gitt en instans med følgende dokument-ID i postjournalen, så kan en regne ut hvor mye som ikke finnes i journalen:

• 2014/2-1
• 2014/5-1
• 2014/5-3

Her ser en at saksnummer 2 og 5 finnes i postjournalen, mens nummerene 1, 3 og 4 mangler. En ser også at i sak 2014/5 mangler dokument 2. Ved hjelp av denne informasjonen har jeg regnet ut hvor stor andel av saksnummer og dokumentløpenummer som ikke har dukket opp i Offentlig Elektronisk Postjournal (OEP). For saksnummer har jeg tatt utgangspunkt i at en ikke trenger å starte på 1, og dermed regnet med området fra laveste til høyeste saksnummer og talt antall unike saksnummer som forekommer i OEP. I dette tilfellet betyr de at 2 av 4 saksnummer er ubrukte (50%). For dokumentløpenummer har jeg tilsvarende tatt utgangspunkt i laveste og høyeste kjente dokumentløpenummer, for å handtere databaser der jeg mangler komplett postjournal. For sak 2014/5 her betyr det at 1 av 3 dokumenter mangler (33%).

Det er flere årsaker til at det kan bli hull i nummerseriene. Feilføring der et dokument tildeles et nytt saksnummer ved en feil, og deretter flyttes inn i riktig sak vil gi et ubrukt saksnummer, da saksnummer skal tildeles i stigende rekkefølge og en ikke får opprette nye saker innimellom gamle saker. Tilsvarende kan skje med dokument-løpenummer. Det er jo heller ikke sikkert at et saksnummer i OEP er det samme som løpenummeret som brukes som saksnummeret i instansens interne datasystem. Kanskje snakker vi om ulike ontologier der en delmengde av interne saksnummer tilsvarer saksnummer i OEP. Hvis like nummer også tildeles andre ting enn saker som skal til OEP vil en tilsvarende få «hull» i saksnumrene i postjournalen.

Jeg er litt usikker på hva denne statistikken egentlig viser, og heller ikke sikker på om det er reelt sett mangler i OEP (som kanskje kunne anses å være kritikkverdig), bare er resultatet av hendelige uhell i nummertildelingen eller resultat av ulik ontologi i OEP og instansens datasystem. Men jeg syntes tallene og variasjonen var så interessant at jeg hadde lyst til å dele dem med mine lesere. Jeg har sortert listen på prosent upubliserte saksnummer for 2014.

Det kunne vært interessant å se hva som skjedde hvis en ba om innsyn i en dokument-ID som ikke finnes i OEP... :) Det hadde også vært interessant å få vite hva årsaken til at noen saksnummer ikke dukker opp i OEP der det er få og mange. Jeg mistenker jo at årsaken ikke er den samme hos Skattedirektoratet og hos Landinfo, selv om andelen upubliserte nummer er ganske lik.

Ethvert dokument som føres i postlisten til en offentlig instans skal vurderes etter offentlighetsloven, for å se om det skal gjøres offentlig tilgjengelige eller ikke. Det noteres så i postlisten om dokumentet er undratt offentlighet eller ikke. For moro skyld laget jeg en oversikt over hvor hemmelighetsfull de ulike som rapporterer til Offentlig Elektronisk Postjournal (OEP) er, basert på hvor stor andel av dokumentene som er undratt offentlighet i postlisten. Jeg hentet ut for de siste to årene, og sorterte på andelen undratt offentlighet i 2014. De minst hemmelighetsfulle instansene i 2014 er på dermed på toppen av denne lista, og en kan se om de er blitt mer eller mindre hemmelighetsfull siden året før. Noen instanser, som Statens landbruksforvaltning, begynte rapporteringen til OEP i 2014 og har dermed ufullstendig statistikk for 2014 og ingen tall fra 2013. Andre begynte i 2013 og har mangelfull statistikk bare for 2013. Instanser som kun rapporterte til OEP i 2013 er ikke med i listen.

Jeg synes det er interessant hvordan instanser som tilsynelatende driver med det samme (som vegvesenet og fylkesmennene) har så stor spredning i hemmeligholdet. Vegvesenet spenner fra 8,8 til 14,0 prosent, mens fylkesmennene spenner fra 13,0 til 50,0 prosent! Mon tro om det er regionale forskjeller som ligger bak, eller om det er kulturforskjeller internt i organisasjonene som er årsaken.

Det er interessant å sammenligne hvor hemmelighetsfulle instansene er med oversikten over hvor mange gamle dokumenter de journalfører som jeg publiserte for tre dager siden.

For to dager siden la jeg ut litt statistikk for Offentlig Elektronisk Postjournal som viste hvor stor andel av postjournalen til ulike instanser som hadde mer enn 180 dager mellom oppført dokumentdato og journalføringsdato (liggetid). Det var stor variasjon, men det er uklart for meg hva det kommer av. Noe er åpenbart feilført, som sykepleiertilbakekallingen skrevet i år 7, mens andre ser ut til å være reelt gamle som avleveringslista fra 2001 som ser ut til å være fra et skippertak for å få arkivert gamle dokumenter. Men etter kommentarer fra leserne innså jeg at det vil være nyttig å dele statistikken i inngående og utgående dokumenter, samt interne notater.

Her er samme statistikk for 2014 som for to dager siden, men delt opp i tre ulike kategorier. Her kan en både se hvem som er flinke til å journalføre egenproduserte dokumenter slik at liggetiden er mindre enn 180 dager, men også hvem som ikke lager interne notater eller i hvert fall ikke publiserer informasjon om dem på Offentlig Elektronisk Postjournal. Jeg må si at jeg er veldig imponert over Fylkesmannen i Oslo og Akershus, som ser ut til å ha kontroll over arkiveringen sin.